-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove IR::Annotations and make IAnnotated to carry annotations inline #4992
base: main
Are you sure you want to change the base?
Conversation
This is PR on top of #4971 for simplicity. As mentioned in #4974, The impact of # of allocations is huge. So, we're 10% less of memory allocations by both total size and number. The runtime impact with GC disabled is huge as well:
So, we're 10% faster here (!) Runtime impact with GC on is much less visible due to huge GC overhead (1.5x):
|
497afd2
to
aed00f8
Compare
sanitizers are broken after #4989 |
@@ -154,7 +157,7 @@ class P4Control : Type_Declaration, INestedNamespace, ISimpleNamespace, IApply, | |||
|
|||
/// A P4-16 action | |||
class P4Action : Declaration, ISimpleNamespace, IAnnotated, IFunctional { | |||
optional Annotations annotations = Annotations::empty; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we get most/all of the memory savings by just using inline
here instead of getting rid of IR::Annotations completely? That might be a simpler change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all, as IR::Annotations
will be still be a Node
and it will still be cloned. Though "invisible" now when outer node is cloned by itself. Plus, there was already a FIXME for this change. I think additional wrapper is not required as annotation is a property of the Node itself, so why do we need to have additional level of indirection? For convenience we can certainly do using Annotations = IR::Vector<IR::Annotation>
here, yes.
Plus I already fixed couple of bugs when it was Annotations (being a Node) queried for the presence of an Annotation. Certainly the check returned always false. Now only IAnnotated
objects could be queried about annotations.
In addition to this: usually we only have 1-2 annotations max (e.g. @name
and that's it). So we can store them inline using e.g. absl::InlineVector
as underlying storage. This would remove almost all Annotation-related memory allocations. But first we'd need to reduce the size of Allocation itself IMO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think additional wrapper is not required as annotation is a property of the Node itself, so why do we need to have additional level of indirection?
I agree.
aed00f8
to
4a82acc
Compare
I rebased the branch after abseil string helpers were merged in. Now it should show the changes more cleanly |
Signed-off-by: Anton Korobeynikov <[email protected]>
initializer_list while there Signed-off-by: Anton Korobeynikov <[email protected]>
Signed-off-by: Anton Korobeynikov <[email protected]>
Lots of cleanups and fixes here and there Signed-off-by: Anton Korobeynikov <[email protected]>
4a82acc
to
fa34687
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you. I went over ir
, midend
and most of frontend
changes (except mainly of P4-14).
annotations.push_back(ann); | ||
} | ||
|
||
Vector<Annotation> addNameAnnotation(cstring name, const Vector<Annotation> &annos) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to put the annotation vector second in this function, while it is first in the previous once?
bool needsParsing : 1; | ||
|
||
/// If this is true this is a structured annotation, and there are some | ||
/// constraints on its contents. | ||
bool structured : 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the bit-field really decrease size of the struct? Since there are the Vector
/IndexedVector
members, I would expect the alignment to be 64bit and therefore it would not really meatter if the 2 bools are 2 bits or 2 bytes. Or is there another reason to use bit-field?
@@ -154,7 +157,7 @@ class P4Control : Type_Declaration, INestedNamespace, ISimpleNamespace, IApply, | |||
|
|||
/// A P4-16 action | |||
class P4Action : Declaration, ISimpleNamespace, IAnnotated, IFunctional { | |||
optional Annotations annotations = Annotations::empty; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think additional wrapper is not required as annotation is a property of the Node itself, so why do we need to have additional level of indirection?
I agree.
@@ -72,10 +73,10 @@ struct StructTypeReplacement : public IHasDbPrint { | |||
flatten(typeMap, cstring::empty, type, type->annotations, vec, policy); | |||
if (type->is<IR::Type_Struct>()) { | |||
replacementType = | |||
new IR::Type_Struct(type->srcInfo, type->name, IR::Annotations::empty, *vec); | |||
new IR::Type_Struct(type->srcInfo, type->name, IR::Vector<IR::Annotation>(), *vec); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the annotations list not optional in this case?
if (const auto *em = mi->to<P4::ExternMethod>()) | ||
return !em->method->hasAnnotation(IR::Annotation::noSideEffectsAnnotation); | ||
if (const auto *ef = mi->to<P4::ExternFunction>()) | ||
return !ef->method->hasAnnotation(IR::Annotation::noSideEffectsAnnotation); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can merge these by using ExternCall
.
Lots of cleanups and fixes here and there